こんにちは。コンサルティング部の崔です。

DVC304:Red Team vs. Blue Team on AWS に参加しましたのでレポートをお届けします。

セッション概要

Red teamers, penetration testers, and attackers can leverage the same tools used by developers to attack AWS accounts. In this session, two technical security experts demonstrate how an attacker can perform reconnaissance and pivoting on AWS, leverage network, AWS Lambda functions, and implementation weaknesses to steal credentials and data. They then show you how to defend your environment from these threats.

This session is part of re:Invent Developer Community Day, a series led by AWS enthusiasts who share first-hand, technical insights on trending topics.

スピーカー

Teri Radichel - CEO, 2nd Sight Lab

Kolby Allen - Platform Engineer, Zipwhip

セッションメモ

今回のセッションは、2名のセキュリティ専門家が攻撃側と守備側に分かれて、攻撃側はネットワーク、AWS Lambda、実装の弱点を活用して認証情報とデータを盗む方法を、守備側はこれらの脅威から自分の環境を守る方法を示します。

攻撃側がどのように情報を盗むか

• 攻撃側はDevOpsチームが利用するツールは同様に使えると想定され、認証情報をファイルに記載していると簡単に盗用されてしまう。
  • aws_access_key_id
  • aws_secret_access_key

• 認証情報からAWS CLIが実行され、データベース名を確認され重要なデータが入っていそうなデータベースが特定される。

• データベースが配置されているsubnetを特定される
  • そのsubnetのNACLやVPCの情報が特定され、データベースに接続可能なセキュリティグループが最終的に特定される

• そこからLambda関数を利用してデータベースの認証情報等を入手し、データベースの内容を盗んでしまう。

• 最終的に次のような流れで、データベース内の重要情報が抜き取られてしまう。

守備側がどのように情報を守るか

• 認証情報の保護
  • フィッシングや取り扱いについて、トレーニング
  • パスワードポリシーの設定とローテーション
  • Multi-factor authentication（MFA）
  • コード 埋め込まれた認証情報を取り除く
•  IAMのベストプラクティス
  • IAM ロール
  • 最小権限

• AWS ShieldやAWS WAFの活用

• ネットワークアーキテクチャ
  • ３層に分けたネットワーク
  • NACLとセキュリティグループはサブネット間で制限する
  • 不要な外部向け通信はブロック

結論

• 攻撃側
  • 攻撃側はDevOpsチームが使っているツールを同様に利用できる
  • APIはアカウント全体をマッピングする情報を取得可能
  • 読み取り専用アクセスはそれでも強力
  • 開放されたネットワークは攻撃側のベストフレンド
• 守備側
  • 制限アクセス
  • 自動デプロイ
  • 必要最小限のみ開放するよう設計されたネットワーク
  • 機密情報はコードに書かない
  • すべてをモニタリング

感想

NACLやセキュリティグループの設定、IAMロール・MFAの設定等、設定自体はそれほど難しいものではないものの、その設定に抜け漏れがあると非常に重大な過失につながることがあります。そうならないためにもこれらの設定について、今一度見直しをする良い機会になればと思います。

以上です。